home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / ietf / 91nov / area.security.91nov.txt < prev    next >
Encoding:
Text File  |  1993-02-17  |  6.8 KB  |  161 lines
  1.  
  2. Security Area
  3.  
  4. Director(s):
  5.  
  6.  
  7.    o Steve Crocker:  crocker@tis.com
  8.  
  9.  
  10. Area Summary reported by Steve Crocker
  11.  
  12. The Security Area within the IETF is responsible for development of
  13. security oriented protocols, security review of RFCs, development of
  14. candidate policies, and review of operational security on the Internet.
  15.  
  16. Much of the work of the Security Area is performed in coordination with
  17. working groups in other areas.  The Security Area Advisory Group (saag)
  18. is a group of security experts which provides both consulting help to
  19. other areas and direct management of working groups within the Security
  20. Area.
  21.  
  22. Security Area Advisory Group (saag)
  23.  
  24. The main bulk of work for this Group consists of a set of formal work
  25. items.  These work items correspond to four types of activities.
  26.  
  27.  
  28.   1. Working groups within the IETF Security area.  These are marked as
  29.      ``Security.''
  30.  
  31.   2. Working groups in allied organizations that function as part of the
  32.      IETF Security Area.  These are marked either ``PSRG'' for the
  33.      Privacy and Security Research Group, or ``TSIG'' for working groups
  34.      within the Trusted Systems Interoperability Group.
  35.  
  36.   3. Security relevant developments within working groups in areas other
  37.      than security.  These are marked according to the relevant area,
  38.      viz., Applications, Internet Services, Network Management, OSI
  39.      Integration, Operational Requirements, Routing, Transport and
  40.      Services, or User Services.
  41.  
  42.   4. Internal work items.  These are topics which do not merit the
  43.      creation of a formal working group but which do need some level of
  44.      attention.  These are assigned to a saag member and followed for
  45.      one or more saag meetings.  These are marked as ``SAAG''.
  46.  
  47.  
  48. The Security Area Advisory Group met during the first and last working
  49. group period of the Santa Fe IETF. The first meeting is used to
  50. coordinate the activities for the week and the second meeting is used to
  51. report on the activities that have occurred.
  52.  
  53. During the week, of the twenty-three open work items on Monday, five
  54. work items were closed and four new work items were opened.  Eight work
  55.  
  56.                                    1
  57.  
  58.  
  59.  
  60.  
  61.  
  62. items received no attention.  The key activities for the week to report
  63. are all working groups in the Security Area:  SNMP Security, Common
  64. Authentication Technology, and Privacy Enhanced Mail.
  65.  
  66. SNMP Security (snmpsec)
  67.  
  68. There are three documents which have been reissued.  There are four
  69. implementations, three of which have been demonstrated to interoperate
  70. with each other.  The final actions are cleaning up the documents,
  71. reviewing them, and submitting them to the IESG for consideration as
  72. Proposed Standards.
  73.  
  74. One of the important technical issues to be discussed was the choice to
  75. be made between message digests:  MD4 and MD5.  It is clear that MD5 is
  76. the right choice for standards actions or something that you want to
  77. invent for some stability.  MD5 does run slower by some amount than MD4,
  78. but the overall equation makes a fairly modest impact.  There will
  79. probably be a lot of performance measurements showing up, but it is
  80. pretty clear that performance is not the critical issue.
  81.  
  82. This decision effects a number of other working groups, each of which
  83. had decided to adopt whatever choice is made by SNMP Security.  These
  84. include the 822 Extensions and PPP Extensions Working Groups.
  85.  
  86. Common Authentication Technology (cat)
  87.  
  88. The basic idea is you have a set of applications that want access to one
  89. or more authentication mechanisms, for example Kerberos or the
  90. Distributed Authentication Security Service (DASS). There is a common
  91. program interface, a general security services application program
  92. interface, that has been defined such that these applications can be
  93. written to be neutral with respect to which mechanism is actually
  94. employed.  The binding with a mechanism takes place at some later time,
  95. currently compile time.
  96.  
  97. The feature of the mechanisms currently proposed is they depend upon a
  98. global identification scheme, i.e., you have a name that exists outside
  99. the context of the machine you are trying to connect from or connect to.
  100. The name identifies a set of credentials that area forwarded on your
  101. behalf.  This raises the question of what happens when there is an
  102. application of the technology on a machine on which your credentials do
  103. not exist, for example a terminal server at an IETF meeting.  Does it
  104. makes sense for one of the underlying mechanisms to be the use of
  105. passwords?
  106.  
  107. This opened up the discussion in multiple directions, but the critical
  108. question is what is the ambition level of the CAT technology, with
  109. respect to a much larger set of issues in security, authentication,
  110. identification, and in particular with respect to authorization.  For
  111. now, CAT will continue down the path it is on.  There will be subsequent
  112. activity to serve these larger functions.
  113.  
  114. There is a set of documents in preparation.  Two Internet Drafts exist
  115. that describe the interface, a basic functional description, and
  116.  
  117.                                    2
  118.  
  119.  
  120.  
  121.  
  122.  
  123. specific C structures.  An Internet Draft exists for each of Kerberos
  124. and DASS.
  125.  
  126. Privacy Enhanced Mail (pem)
  127.  
  128. There was a great deal of controversy during the Atlanta meeting, but a
  129. number of meetings and interactions have occurred since then, resulting
  130. in substantial progress and resolution of major issues.  It is worth
  131. noting there was a booth and demonstrations at INTEROP, where multiple
  132. interoperating implementations were heavily attended during the whole
  133. period.  It was a big success for everybody.
  134.  
  135. The key decision that came out of the meetings following Atlanta was to
  136. open the range of policies.  There had been a single policy coming into
  137. existence emphasizing very high assurance that the binding of the name
  138. and public key in the certificate actually represented a real person and
  139. had not been forged.  The controversy was focused on whether or not the
  140. high assurance was appropriate in all cases.  The resolution was to push
  141. the notion of assurance down one level in the certificate validation
  142. hierarchy and create what are now called Policy Certification
  143. Authorities, which are bound together by a policy neutral administrative
  144. function called the Internet Certificate Authority.  The current
  145. candidate policies are a continuation of the high assurance policy, a
  146. mid-range policy, some support for residential users, and support for
  147. persona users.
  148.  
  149. There will be two bodies of software available.  There is an
  150. implementation Trusted Information Systems has been developing for some
  151. time, that will include modifications to MH and a general purpose
  152. filter, which will be distributed in source code form with an object
  153. version of the cryptography supplied by RSA Data Security Incorporated
  154. (RSADSI). RSADSI will separately make available a limited size tool kit,
  155. in source form, on a you-build-it basis.  Neither of these is intended
  156. for commercial applications.
  157.  
  158.  
  159.  
  160.                                    3
  161.